the GuideLines for this project was for the game to be specifically built to run for either Mobile or Switch. My group decided on the game being built for mobile specifically Androids within the last 3 years. the time frame to complete the game demo was 6 weeks like the previous project and the final product was to be a high-fidelity prototype. The main theme of the game could be anything of our choosing but we had to include something that fit with the UN sustainable development goal. We were assigned into groups of 5-7 with set roles decided in a group discussion with me being assigned as one of 2 coders to build the main mechanics of the game with me focusing on almost every other mechanic except walking in a white box to conduct tests and also made some models for the final game at the end. In the end, I ended up completing the code for base game mechanics but was left without most of the intended assets so the final product was left mostly looking the same as the white box. however, most of the coding I did was done by myself with some help from accessible YouTube tutorials to get an understanding of what I needed to do. next time I should focus on making scripts with more of a variety of functions as some of the scripts could of been merged together instead of being a couple of different scripts floating around and also try and implement the use of statemachines to clean up coding.
The software used include: 1. Unity 2. Visual Studios 3. Blender also used youtube videos for some help with coding and filling in missing pieces of knowladge.
The Gannt chart was created at the start of the project as preproduction to figure out how much time should be allotted to each part of the project and what can be worked at side by side to help with efficiency and setting aside time in case of emergency or last minute tweaks that needs to be done.
I created the mind map to help with the idea generation process in the beginning stages and set the outlines of our options what we needed the software we were going to use and the specific requirements that we needed to uphold while making the game.
The code for the Unity selection manager works by first checking that it is the only instance of it running by when the code loads it checks if there's another instance and if there is and it isn't called "this" it gets destroyed If there isn't another instance the current one gets called "this". the selection manager works by creating lists for in this case all the units in the game where it finds all instances of the gameobject that's declared in the inspector then the other lists remains empty where when you click on a unit they get put into the other list which runs a routine that enables the movement code on the unit prefab. the actual selecting is done at the start of the code it gets a reference to the main camera and for every frame it checks if the player clicked on the screen and it uses a raycast from the position of the click on the main camera and fires the ray in a straight line directly ahead and if it hits something that is on a laymask declared clickable it selects the gameobject it hit. if the ray doesn't hit anything that's declared hittable it deselects whatever is in the selected list and disables that gameobjects movement script. this script was also used for other mechanics like gathering resources. I might have been able to improve the script by having to use fewer individual lists and instead one big list with everything in it and figure out what happens to the object through tags but this may also be a worse way as I haven't used lists often.
This code is implemented onto the prefab of anything selectable so when they load in they automatically get added into the allUnitsList so the game can always keep track of how many units are active at one time. could maybe combine the similar scripts for this into one and check tags for where they belong and sort them that way instead of having a different script for every list.
The zooming works first by setting the minimum and maximum distance that you can zoom in and out with then every frame the code checks to see if you actively have 2 fingers touching the screen if that is true it declares the input of both fingers individually so the code can use the positions to figure out what way the fingers are moving by comparing the position of the fingers when they first touched the screen and the current position and with that current value and previous position value from both fingers then they get minus from each other and to see if they were moving apart or together then zoom by the value of the difference of the current and previous magnitude. the zooming function just gets the main camera orthographic size clamps how far it can zoom in and out and then changes the size based on the value of difference.
The camera controller works by declaring what we want the camera to follow by grabbing their position and adding an offset that is declared in the start to add padding then setting the allowed camera boundary by mathf.Clamping the position of the X and Y axis the actual movement comes from the transform position to equal the target position with a smoothdamp added. could have added features to allow for customisable stagger of camera and the smooth time so the player can choose.
At the start, it sets the current health to a predetermined max health which can be changed within unity itself as this script can be applied to anything that needs health. the if statements tell whatever the script is attached to destroy itself when their health is less than or equal to zero this script was made in the first project but tweaked slightly for the current game.
The damage script lets anything that is attached take damage as long as it completes the if statements. this script was also from the first project as it still worked well enough for this game that I only had to tweak it slightly
This script allows the enemy to track and chase you when you enter the declared activation range. It traversed the environment using a NavMeshAgent. At the start, it grabs the navmesh on the enemy and sets a variable player where it tracks the position of any game object with the tagged player on it, everyframe it checks the distance to the player by getting the player's position and its current position. if the distance to the player is within the activation radius it sets the destination to the transform position of the player else the destination is set to the enemy's current position so it doesn't move.
The resource manager is a small script where it has the veriables for each resource at the start and declares that when the game has just loaded they should both equal zero.
This script is added onto every resource so it gets added to the main games list of all resources avalible and when they are destroyed they get removed from the list.
The gather script grabs a referance to the resource manager and uses if statements for each resource type so when the unit runs into the gameobject it checks what tag the resource has and depending the certain resource gets added to the count on the resource manager and destroys the gameobject. this can be improved in the future by instead of simply running into the object you can proform an action to destroy and gather the resources.
the steps involved to create the tree are:
the top of the tree was done by:
the cogs were made by:
The steps involved in making the house:
the doors were made by:
supports were made by:
The windows were done similarly to the door but the inner struts are crossed the railing for the balcony was made with cylinders and the corners are where 2 cylinders faces are selected and you bridge the gap and bevel it.
Planting troughs are made by:
Cog was made the same way as with the tree
The top observatory was made by:
The steps involved in making the rocks:
How I made the steampunk robot torso
How I made the steampunk robot limbs
Arms and legs were both done the same way
How I made the steampunk robot hands
size so the hole in the cogs matches the circumference of the cylinder
